Unpin array api strict #10983
Unpin array api strict #10983
Conversation
|
Thank you for opening this pull request! It may take us a few days to respond here, so thank you for being patient. |
github-actions
bot
added
CI
|
I don't understand why the mypy tests fail after these changes, so can't really come up with a way to fix this (except for giving an ignore to mypy :) ) |
There was a problem hiding this comment.
Array api strict is now typed since 2.4.0: data-apis/array-api-strict#135
This is the erroring code:
xarray/xarray/tests/test_dtypes.py
Lines 9 to 18 in 58594f8
Redefinitions with different types is in general not a good idea for type safety. mypy choose the first one and goes from there. Since array api strict wasn't typed <2.4.0, the type was
Any which made the except case valid too, not anymore though.
We usually just ignore in these optional import cases, examples are here:
Lines 47 to 50 in 58594f8
xarray/tests/test_array_api.py
Outdated
| actual = xp_arr + 7 | ||
| assert isinstance(actual.data, Array) | ||
| assert_equal(actual, expected) | ||
| assert_equal(expected, actual) |
There was a problem hiding this comment.
I think array api strict had the right idea here.
It's not a good idea to assume different types of arrays will work with each other.
Should we instead explicitly convert to numpy?
actual = np.asarray(xp_arr + 7)
There was a problem hiding this comment.
Thanks for you insight @Illviljan. Changing the array-api-strict to np arrays sounds like a good plan.
I think we want to keep the assert isinstance(xp_arr.data, Array) check after the array operations, and since actual should be a xr.DataArray, I changed it now to:
actual_np = actual.copy(data=np.asarray(actual.data))
assert_equal(actual_np, expected)
2 participants
Closes #10427
In array-api-strict>2.4.1, arithmetic operations no longer accept NumPy arrays. By inverting the assert_equal variables, we use numpy's
__eq__instead of the array-api-strict__eq__